Virtual private server technology allows a dedicated server to be partitioned into multiple virtual partitions, each of which functions as a separate virtual machine although everything in essence is operated off the server itself. A virtual private server enables a customer to enjoy the security, performance and all administrative features of a dedicated server which cannot be found on virtual hosting environment. Each virtual server is isolated from the other virtual servers, thus allowing the customer to install their choice of Operating System (“OS”) and software applications.
Virtual private server technology is ideally suited to heterogeneous environments and offers high-end multiple OS capability that enables execution of all of the leading operating systems on the same system concurrently in a consolidated environment. In one exemplary embodiment, virtual private server technology may be implemented within a server system having a multicellular architecture where the basic building block of the server is a cell, or cell board. For instance, each server may contain several cell boards, which are plugged into the backplane of the cabinet. Each cell board can be a self-contained unit, with a symmetric multiprocessor (“SMP”) arrangement, main memory, up to eight processors per board (four CPU sockets per board with 2 CPUs per socket) and all necessary hardware. In one embodiment, the processors are implemented using Intel Itanium series processors. Each cell has an optional link to an I/O chassis. Where provided, a cell may connect to its remote I/O chassis through an I/O cable link. This enhances modularity, ensuring independent scalability of processors, memory, and I/O.
Additionally, in some exemplary implementations, a server system embodying the virtual private server technology may provide both hard and virtual, or soft, partitioning support. A hard partition includes, at a minimum, a cell board and an I/O chassis; however, the system can be hard partitioned into larger partitions, which could include all of the cell boards and one or more I/O chassis. The soft partitions can be dynamically resized for the highest degree of flexibility.
The Extensible Firmware Interface (EFI) specification defines a new model for an interface between operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the OS and its loader. Together, these provide a standard environment for booting an OS and running pre-boot applications. The EFI specification is primarily intended for Intel IA-32 and Itanium architecture-based computers and is an outgrowth of the “Intel Boot Initiative” (IBI) program that began in 1998. As shown in FIG. 1, EFI 100 provides an interface between an OS loader 102 and system firmware 104 associated with system hardware 106.
All data pointers and function pointers are maintained in the firmware 104. In one prior art embodiment, whenever a pointer is used, a call is made to a “MapAddress” function. The MapAddress function determines the current mode of the calling processor (i.e., virtual or physical) by checking the contents of a processor status register (“PSR”). If the calling processor is running in virtual mode, the MapAddress function converts the physical address passed to the MapAddress function to a virtual address and returns the virtual address to the portion of code that called the function. In this embodiment, the physical address is mapped to the corresponding virtual address with reference to a Physical-to-Virtual Address Map, which is supplied by the OS through a call to an EFI standard function “SetVirtualAddressMap”. This embodiment performs well for hard partitions; however, to be used with virtual partitioning, a complete copy of firmware would have to be maintained for each virtual partition. Clearly, this is inefficient and, in many cases, cost-prohibitive.
In another prior art embodiment, which is implemented in the EFI, when an OS begins operating in virtual mode, the EFI goes through a list of pointers maintained thereby and changes each to reflect its associated virtual address. In this embodiment, any software module that contains a pointer in the list maintained by the EFI registers a “callback” with the system. When the OS goes virtual, a function calls all of the modules that have registered and each of the modules changes all of the pointers therein from their physical addresses to their associated virtual addresses. In this embodiment, once the OS goes virtual, it cannot go back. Again, this so-called solution is both inefficient and, in some cases, ineffective.